Scheduling requirements #85
Conversation
| COMPONENT: Scheduling | ||
| TITLE: Priority-Based Selection | ||
| STATEMENT: >>> | ||
| The scheduler shall select the highest priority ready thread as the current thread from the ready queue. |
There was a problem hiding this comment.
- It is not merely the highest priority thread. It is the highest priority thread that is permitted to execute on the CPU.
- The ready queue is not the only source of ready threads. In SMP, the currently executing thread is not in the ready queue.
- If no thread is found that satisfies the requirements in those sources, the idle thread is selected (which is also not in the ready queue).
| COMPONENT: Scheduling | ||
| TITLE: Ready Queue Scalability | ||
| STATEMENT: >>> | ||
| The scheduler shall support configurable ready queue implementations (DUMB/RBTREE/MULTIQ) with O(1) or O(log n) time complexity as documented. |
There was a problem hiding this comment.
The dumb queue is O(n). As presently written, this disallows them
Perhaps something along the lines of ...
The scheduler shall support a ready queue set that can be configured for either dumb, rbtree or multiq and whose time complexity is O(n), O(log n), or O(1) respectively.
There was a problem hiding this comment.
drop the priority queue names from the requirement, those are implementation details. DUMB btw is not called DUMB anymore.
| COMPONENT: Scheduling | ||
| TITLE: Mandatory Context Switch Triggers | ||
| STATEMENT: >>> | ||
| The system shall trigger rescheduling during: thread state transitions (→SUSPENDED/WAITING), ISR returns, explicit k_yield() calls, and time slice expiration. |
There was a problem hiding this comment.
Not sure if this is meant to be an exhaustive list of when we trigger a rescheduling. If so, then we should also include the modification of the static priority.
? thread state transitions (blocked/ready) ?
| COMPONENT: Scheduling | ||
| TITLE: Atomic Rescheduling | ||
| STATEMENT: >>> | ||
| Rescheduling shall occur atomically at designated points to prevent partial state corruption during thread swaps. |
There was a problem hiding this comment.
As written, this raises the possibility that rescheduling could be non-atomic at other points.
Perhaps ...
Rescheduling shall both occur at designated points and be atomic to prevent ...
| COMPONENT: Scheduling | ||
| TITLE: Cooperative Thread Non-Preemption | ||
| STATEMENT: >>> | ||
| Cooperative threads (negative priority) shall retain execution until explicitly yielding or entering unready state. |
There was a problem hiding this comment.
negative priority -> negative static priority.
Not sure how to integrate the following information ... Meta IRQ threads may preempt a cooperative thread, but then that preempted cooperative thread must be immediately scheduled afterwards
| COMPONENT: Scheduling | ||
| TITLE: Sleep Duration Accuracy | ||
| STATEMENT: >>> | ||
| k_sleep() shall delay thread execution within ±1 tick of requested duration. |
There was a problem hiding this comment.
k_sleep() shall, unless awakened prematurely via k_wakeup(), shall delay thread execution ...
| COMPONENT: Scheduling | ||
| TITLE: Busy Wait Non-Relinquishing | ||
| STATEMENT: >>> | ||
| k_busy_wait() shall not yield CPU or trigger rescheduling during delay. |
There was a problem hiding this comment.
k_busy_wait() shall not trigger a rescheduling
| COMPONENT: Scheduling | ||
| TITLE: Cross-CPU Atomicity | ||
| STATEMENT: >>> | ||
| Spinlocks shall enforce cross-CPU mutual exclusion for scheduler data structures. |
There was a problem hiding this comment.
Scheduler data structures that require cross-CPU mutual exclusion shall be guarded by spinlocks
| TITLE: Deadline Enforcement (EDF) | ||
| STATEMENT: >>> | ||
| When EDF scheduling is enabled, the system shall prioritize threads with equal static priority based on earliest deadline. | ||
| When earliest-deadline-first (EDF) scheduling is enabled, the scheduler shall prioritize threads with equal static priority based on earliest deadline. |
There was a problem hiding this comment.
... the scheduler shall only consider the deadline when prioritizing between two or more threads of equal static priority. In such cases, the thread with the earliest deadline shall be considered to have the highest priority.
| TITLE: Ready Queue Scalability | ||
| STATEMENT: >>> | ||
| The scheduler shall support configurable ready queue implementations (DUMB/RBTREE/MULTIQ) with O(1) or O(log n) time complexity as documented. | ||
| The scheduler shall support configurable ready queue implementations. |
There was a problem hiding this comment.
??? The scheduler shall support ready queue implementations that are configurable at build time. ???
The suggested text still feels clumsy. The aim was to make it more clear that the configurability is not done at run time.
Moved the requirements in thread_scheduling.sdoc to submodule documents that align with their needs.
3 participants
TBD - Adding Draft Pull Request to prevent rework
Currently working to understand how to handle the overlap of the pre-existing software requirements
thread_sheduling.It appears we should ensure consistency between the documentation sections (Ex:
thread_scheduling->Scheduling).